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(54) Method for wide area network service location 



(57) A method for a client to locate a particular serv- 
ice from a service provider on wide area computer net- 
works. The method includes multicasting of an adver- 
tisement from a service provider, which advertisement 



is detected by a Service Broker and in turn multicast into 
the wide area computer network. A client queries the 
network when seeking a particular service and receives 
in turn the address of the Broker and a Server to obtain 
the service desired. 
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Description 

Field of the Invention 

The instant invention relates to the general problem 
of service location in wide area computer networks and, 
more particularly, to the specific problem which arises 
when a user wishes to locate some service, such as a 
media bridge, internet telephony gateway, H.323 Gate- 
keeper, umcastto multicast bridge, etc., which has some 
desired characteristics, but whose location (in terms of 
network aadress, domain or geographical location) is 
completely unknown and may be anywhere on the pub- 
lic network. 

Background of the Invention 

Today, there exists a number of examples of wide 
area services. One is media bridges, which are devices 
used for mixing voice or video together for multipoint 
conferences. Another might be a media server which 
contains movies and multimedia accessible to the user 
for playback. Another example are Internet telephone 
gateways. These devices allow Internet hosts to com- 
municate with standard 'POTS' telephone users by 
translating Internet "telephony to traditional telephony. 
Yet another example is a multicast to unicast bridge, 
which would allow unicast-only endpoints to receive 
multicast. 

Generally, with currently existing technology, serv- 
ice location mechanisms need to be involved for every 
call set-up. This makes their location a time critical, and 
potentially network ana CPU intensive operation. Fur- 
thermore, reiaymg internet telephony calls to the PSTN 
results in cost for the gateway provider which must 
somehow be passed on to the remote user. This also 
requires security mechanisms to provide authentica- 
tion and authenticity in an international environment. 

Prior art systems and devices exist for locating serv- 
ices, but none work well for wide area network service 
location. For example, some prior art publications have 
taught the use of DNS records for finding services in a 
particular domain. See for example A. Gulbranasen. P. 
Vixie. *A DNS RR for Specifying the Location of Services 
{DNS SRV) m , IETF Request for Comments 2052. Octo- 
oer 1996. andR. Moais. M. Hamilton, P. Leach. 'Finding 
SiufT. IETF intemetOratt dratt-iett-srvloc-discovery- 
02. ixt. Work in progress. Prior art puolications have also 
addressed the problem of finding fax gateways in a par- 
ticular telephone exchange: see. for example. C. Mala- 
mud. M. Rose, 'Principles of Operation for TPC INT 
Subdomam: General Pnncipies and Policy*. IETF Re- 
quest for Comments 1530. October 1993. 

The use of DNS requires the client to know the do- 
main name where the server is located, which is gener- 
ally not oossible. The Service Location Protocol, see for 
axamoie. J Veizades. t. Gunman C Perkins. S Kap- 
lan Sen/ ice Location Protocol". IETF Request for Com- 



ments 2165, June 1997, is used for location of services 
in an administrative domain, but does not work for wide 
area networks as it ends up using excessive bandwidth 
as more servers and clients use it. The Session An- 

s nouncement Protocol (SAP). M. Handley, "SAP - Ses- 
sion Announcement Protocol", IETF Internet Draft, 
Work in Progress, allows for announcement of services, 
but requires an excessive amount of time for clients to 
learn about them. Web search engines, such as Lycos 

to and Alta Vista, can also be used for the location of serv- 
ices. However, sucn search engines tend to generate 
excessive traffic, and service location control rests in the 
hands of a few, dedicated search facilities. This has lim- 
ited scalability. 

is It is, therefore, an object of the instant invention to 
provide a solution to the service location problem which 
is efficient and scalable both in use of bandwidth and 
CPU power. 

It is a further object of the instant invention to pro- 
20 vide a protocol architecture which allows clienls in a data 
network to readily locate services in a wide area net- 
work. 

It is another object of the instant invention to provide 
a protocol architecture which scales to an infinite 
2$ number of clients and millions of servers without requir- _ 
ing excessive bandwidths, while at the same time being 
fast, simple and flexible. 

Summary of the Invention 

30 

The claimed invention comprises a protocol archi- 
tecture which allows clients connected to a data network 
to locate services in a wide area network such as the 
internet. The invention scales to an infinite number of 

35 clients and millions of servers without requiring exces- 
sive bandwidths and is also last, simple anc flexible. 

The inventive method includes activating a server 
X to provide a service A to clients and when activated 
server A broadcasts an advertisement for service A to 

•to a multicast group G<, . 

Broker Y stores the advertisement for service A in 
its database and broadcasts the aavertisement lor serv- 
ice A to a multicast group G 2 . which advertisement is 
detected by Directory Agent Z and storea in Zs data 

45 base. 

A client, looking to find a server for service A queries 
Directory Agent Z and receives the address (or Broker 
Y. wno then provides lo the client the aadress Icr server 
X. 

so The client is then able to contact server X to ootain 
service A. 

Brief Description of Drawings 

ss This invention is pointed out with particularity m the 
appenoed claims. The above and f urther advantages of 
this invention may be better understood oy referring to 
the foltowng description taKen m conjunction witn tne 
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accompanying drawings in which: 

FIG. 1 is a diagram of the protocol architecture of 
the instant invention allowing clients in a data net- 
work to locate services in the wide area network: 
and 

FIG. 2 describes the flow of events which occurs 
when the system protocol architecture is initialized. 

Detailed Description of the Invention 

We formally define the wide area service location 
problem as follows. A client on a computer network (IP 
based, ATM, etc.) wishes to find a server that provides 
a service. There are no restrictions on the name space, 
network address space, geographical location, or ad- 
ministrative domain where the server may be located. 
Furthermore, the client has no knowledge of the location 
of the server. It has only a definition of specific attributes 
or constrain Is (e.g., supported protocols, type of billing 
used, cost) which are desirable or metrics to minimize 
or maximize (e.g.. cost, quality, distance). A protocol is 
needed to allow the ciient to find the server. The require- 
ments for such a protocol are: 

1 . Scalable; The protocol should work for many cli- 
ents and servers, without using excessive network 
bandwidth, and without requiring too much time to 
locate the service. 

2. Allow for costs: Network servers may charge for 
their services. The protocol should albw a client to 
choose a server based on cost minimization. 

3. Allow for distance: A client may require a server 
to be close to it, in order to minimize network delays. 
It should be possible to locate a server based on its 
proximity to the client. 

4. Support authentification: A client my want to 
know that a server is really trustworthy. Mecha- 
nisms must exist for authenticating and verifying the 
services provided by a server. 

The inventive architecture for the instant invention 
which fulfills these requirements is shown m FIG. 1 . The 
various components of the architecture are defined as 
follows: 

Referring first to the Servers A-D shown in FIG. 1. 
they advertise using network multicast in order to let cli- 
ents use their services. To do sc. they send messages 
into a multicast group, describing the attributes and cost 
structure of the services they provide. 

For each service, a plurality of multicast addresses 
are defined. These are computeo as a string hasn of the 
service. Service Brokers (shown in FIG. 1 ) listen to this 
multicast address. In addition, any Server wisning to aa- 
vertise this service also listens to this address. By lis- 
tening to this address, a Server wishing to aavertise on 
it can keep track of the number of other Servers also 
advertising 



When using multicast to distribute information 
about sen/ices, some kind of control must be exerted to 
limit the frequency of advertisements from a server. If 
the frequency were fixed, the total number of packets 
s sent to the multicast group, and received at each broker 
(defined below), would grow linearly with the number of 
servers advertising. This can lead to congestion and 
poor performance. To deal with this, the frequency of the 
advertisements from a server is set to scale back based 
j o on a simple technique. 

Any server which advertises to a multicast group G 
also joins and listens to the group. It counts the number 
of distinct other servers which send advertisements to 
the group. Lef s say N other servers are heard from. The 
7 5 period of advertisements from the server is then set to 
N times some basic penoc Tb. This limits the total 
amount of bandwidth on a multicast group to roughly 
one packet every Tb seconds. This is independent of 
the number of servers advertising. The bandwidth us- 
20 age thus scales well, al the expense of less frequent 
advertisements. 

Some additional aspects of this basic "tack-off" al- 
gorithm can also be used: 

25 1 . The period is always made greater than some 
minimum 

2. The minimum period increases with the age of 
the advertisement. The age is defined as the 
number of times the exact same advertisement has 

30 already been sent. When any parameter of the ad- 
vertisement changes, the age is reset to zero. This 
allows older advertisements to be sent less fre- 
quently. 

3. A random factor is added so that the actual period 
35 varies randomly between 1/2 and 3/2 of whatever 

the deterministic period, computed above, turns out 
to be. The random factor helps avoid some synchro- 
nization pathologies that can occur. 

•*o Lets say a Server hears N other servers. We define 
a parameter CONFIG J NTERVAL_i 2. which is the av- 
erage worst-case interval of 1 kbyte packets to be trans- 
mitted, summed across all servers, into the multicast 
group. Each Server wishing to send an advertisement 

4 5 of size < will periodically sena the advertisement with a 
period T equal to: 

T=fl(1/2)max(CONFIGJNTERVAL_l3'F(age), 
so N*CONFIG_INTERVAL_12*K/102 4), 

where 

F(age) is a function when starts at some fractional 
power of two. 2 A (-CONFIG_INTEFVAL_14) wnenever 
53 an advertisement is different from the previous. For 
each subsequent advertisement which is not different 
from the previous. Ft'age) douoles. until it "»its i. ana 
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then it stays fixed at 1 . We also define R(1/2) as a ran- 
dom variable uniformly distributed between 1/2 and 3/2. 
Fdr«cample; say that CONFIG JNTERVAC.1 2 is 64ms. 
Tnis means that the total rate of packets sent into the 
group will be 128 kbps when group sizes are large. If 
there are 1000 servers, each sending 1 kByte packets, 
each one will get to advertise once a minute. When 
group sizes are smaller, the packet rate remains at 1/ 
CONFIG_INTERVAL_1 3 (perhaps 32 kbps) during 
steady state. However, when an advertisement chang- 
es, the rate can temporarily increase (but not above 
128kpbs) to hasten the broadcast of this announce- 
ment. 

This mechanism allows for the number of Servers 
to grow without causing an increase in the bandwidth 
used on the multicast address. A similar mechanism is 
used in RTP to provide scalability, (described by J. 
Rosenberg and H. Schulzrinne, in "Timer Reconsidera- 
tion For Enhanced RTP Scalability 0 , proceedings of the 
IEEE, Infocom '98. The advantage of this approach is 
to solve two of the limitations of the prior art. First, Serv- 
ers do not need to know the actual addresses of Bro- 
kers. This eliminates the need for wide-area multicast 
searches and/or Broker advertisements (used in the 
Service Location Protocol). It also makes the system dy- 
namic. As soon as a new Broker is turned on. it can im- 
medtatery learn about new services, and this process is 
transparent to the servers providing the service (this is 
not the case for the web search engines, for example), 
it also solves the problems of excessive load on brokers. 
The rate is now finely controlled, independent of the 
number of Servers. 

Servers that are not multicast capable, or which do 
not want to subscribe to the service advertisement mul- 
ticast group for reasons of bandwidth or complexity may 
use Notary to diffuse their service advertisements as de- 
scribed below. 

Turning now to a Service Broker (shown in FIG. 1 ), 
this element of the architecture accepts service re- 
quests and service type requests from clients. These re- 
quests ask for the location of a Server matching a set of 
cnteria described by the client. The Broker answers with 
service replies and service type replies. A Broker gen- 
erally handles service requests for one or several spe- 
cific services; that is why it is called a Service Broker. 
This is required in order to scale the disk storage and 
processing requirements for Brokers. It is also desirable 
since different services may have different requirements 
for matching client requests. For example, the Internet 
telepnony gateway service may often require searches 
for Servers which provide the cheapest cost for calling 
a specific destination. Database searches can be organ- 
ized for thts kind of query, but only if the broker knows 
that it will receive mostly or only these type of service 
requests. 

Like a Server, the Broker multicasts service an- 
nouncements if a Broker offers a service location for 
service X. men it will aavertise itself as an offering serv- 



ice X -broker. For example, a Broker offering a media 
server broker service may use a URL: 

service: mediaserver-brokery/mymachine.nnydo- 
main.com:800 

5 Brokers themselves can have various attributes 
which define the broker service they provide. For exam- 
ple, this might be a typical attribute specification for an 
Internet telephony gateway broker: 
(NUMBER J3ATEWAYS=10C0), 

io (AUTHENTlCATION=STRONG) 

The would define this telephony gateway broker as 
having a database of around 1000 gateways. The au- 
thentication attribute indicates that this broker provides 
strong assurances of the correctness of the gateway at- 

J 5 tributes it stores. 

Brokers can be additionally programmed to imple- 
ment some kind of policy, local to the administrator of 
the Broker. This policy may restrict the set of Servers 
whose advertisements are kept by the particular Broker. 

20 For example, lets say a major ISP is running a broker 
service for telephony gateways for its customers. The 
ISP may decide that the Broker should reject all internet 
telephony gateway service advertisements from Serv- 
ers run by a competing ISP. As another example, a Bro- 

25 _ ker may have limited disk space, and may drop adver- - 
tisements for Servers which it believes are unhkety to 
be used by any of its clients, based, say, on past history 
togs of service requests. It should be possible for any 
sort of policy to be implemented. However, Brokers 

30 should indicate the policy attributes in their service ad- 
vertisement. 

The use of Brokers for a particular service also adds 
more scalability. Requests requiring attribute minimiza- 
tion can be considerably more CPU intensive than sim- 

35 pie look-ups. As the quenes for a particular service in- 
crease, and begin to exceed the processing capabilities 
of a Broker, additional Brokers can be added to distrib- 
ute the bad. This load distribution can be implemented 
easily in the directory agent, to which Brokers are reg- 

40 istered. The entire process becomes transparent to the 
clients and to the Servers. 

The main limitation to scalability lor the Brokers is 
the processing burden to search a large number of 
records. If the number of Servers for a particular service 

-*5 begins to exceed several tens of thousands, the storage 
requirements for them, and the time for even a single 
search of the database for a match, can become exces- 
sive. In this scenario. Brokers always have the option of 
implementing some kind of policy to restrict the size of 

50 the database. As faster machines ana bigger disks be- 
come available, these policies can be lifted. Further- 
more, such restrictions open up the possibility of market 
competition for broker service. If a Broker is willing to 
buy a big enough disk and fast enough machine to store 

55 and search every Server, that Broker can attract more 
customers to the broker service. 

The use of Brokers allows a client to find out about 
any particular service, once it can find a Broker for that 
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service. How does a client find a broker for a particular 
service' To accomplish this, a Directory Agent (FIG. 1) 
may be used. This device is like a Broker. It listens to a 
particular multicast address to find out services, and ft 
answers client queries for the services it knows about. 5 
However, tt knows only about a very specific set of serv- 
ices: Broker services. This device is contacted first by a 
client to find out a Broker for a particular service. Gen- 
erally, the client must know about its Directory Agent. It 
can team this information by DHCP manual configura- io 
tion. or via the service location protocol. 

A client (FIG. 1 ), of course, is a system which wants - 
to find the address of a Server which can provide some 
service desired by the client. 

A Directory Agent can also function as a Broker and '5 
maintain a data base listing available services. In this 
instance, the Directory Agent would provide service in- 
formation to a client without involving a Broker. Also, of 
course, it is possible that a Directory Agent could pro- 
vide information available from a Broker directly to a cti- 20 
ent without identifying any particular Broker. 

The final addition to the inventive architecture is a 
new device which we call a Notary. Its purpose is to less- 
en the burden of authentication which is placed on Bro- 
kers, or to support non-mutticast capable Servers. In- 2s 
stead of registering directly with all the Brokers by mul- 
ticasting its advertisement, a Server will instead register 
with a Notary. It is the job of this Notary to provide some 
form of authentication for the servers which it repre- 
sents Once authenticated, the Notary acts as a proxy 30 
for those Servers, multicasting the advertisements for 
them. The form of the service advertisements is nearly 
identical to that ot a Server. The exception is that all the 
authentication information in the message is used to au- 
thenticate the Notary, and is the same for all Servers 35 
being advertised from this Notary. This lessens the bur- 
den of authentication to that of a single Notary, instead 
of many Servers. 

Due to political or technical problems regarding 
cryptographic tecnnologies, a unified strong authentica- 
tion mechanism may not be in place very soon. The use 
of Notaries allows the servers to authenticate them- 
selves to the Notary oy any local or proprietary scheme. 

!n general, for services that involve billing authenti- 
cation 01 the Server may not be enougn. The user may J * 
want some assurance aocut the trustworthiness ot the 
remote service operator. Notary services could be pro- 
vided by authorities of sufficient influence and reputation 
to be trusted by users. Such authorities may for exam- 
ple, police misbehaving service providers they rep re- so 
sent, using non-electronic means ouch as auaiting fi- 
nancial records, etc.). This kind of model already exists: 
credit card companies will absorb the costs of fraudulent 
vendors, ano revoke their capacities :o use the credit 
cara to cnarge customers. ss 

Another requirement is for clients to know, at least 
rougniy. how aistant a Server is it is aesiraole for a client 
:o mciuce seme kind of distance metric in a service re- 



quest to a Broker. 

To support this. Servers should include, in all serv- 
ice advertisements, an attrfoute called INITIAL.TTL.^ 
This attribute indicates the value of the TTL (Time to live) 
field used in the IP packet containing the advertisement. 
When a Broker hears this advertisement on the multi- 
cast address, it notes the TTL in the IP packet when it 
arnved. and the value of the INIT1AL_TTL attribute. 
From this, a Broker can ascertain the number of hops 
from the server to itself. Similarly, when clients send a 
service request, they also include the INITIAL_TTL at- 
tribute in the request. When received at the Broker this 
allows the Broker to know how distant the client is from 
itself. 

In the service request, a client may optionally in- 
clude the DISTANCE attribute, anc specify any allowa- 
ble value for it. A Broker can compute the attribute for 
each record, on a per client basts, by some kind of com- 
bination of the server-to-broker and client-to-broker hop 
counts. The advantage of this scheme is that it does not 
require any sort of additional messages to compute dis- 
tance metrics. 

The flow chart in FIG. 2 describes the flow of events 
which occurs when the system is initialized. It should be 
noted that since the protocol is executed by independent 
network entities, tfciejemporal order of events may vary. 

What has been described is the problem of location 
of services in the wide area Internet. The proposed oaw 
architecture for resolving these drawbacks: multicasting 
of registrations, service specific brokers, distance met- 
rics and hierarchical authentication services via nota- 
ries, solves the problems present in prior art systems. 

Claims 

1. A method for locating services in a 'wide area inter- 
net network, compnsmg the steps of 

receiving a communication from a Server X de- 
siring to provide a service A to a client connect- 
ed to the internet. 

penodtcally multicasting an advertisement for 
service A from Server X to a multicast grouo . 
storing, in a Broker Y's dataoase. me aavemse- 
ment for service A multicast by Server X. 
processing a request from client C to Broker Y 
for a Server providing service A. and 
providing from Broker Y to client C an address 
for Server X to obtain Service A. 

2. A method for locating services in a wide area inter- 
net network in accorcancc with Claim 1 further in- 
cluding the steps of: 

periodically multicasting from Broker Y an ad- 
vertisement for Service Servic9--i-3rcker o 
multicast grouo 3 ; 
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storing, in a Directory Agent Zs database, the 
advertisement multicast by Broker Y. 
processing a communication from client C who 
is seeking a Server for service A, and relaying 
said communication to Directory Agent Z. 5 
initiating a database search by Directory Agent 
Z for providers of Service Service-A-Broker 
locating Broker Y in response to said database 
search, and 

reiurning an address for Broker Y to client C. io 

A method for locating services in a wide area inte- 
rnet network in accordance with Claim 2. wherein 
said locating step further includes the steps of: 

15 

querying Broker Y on behalf of client C. and re- 
turning an address for Server X. provided by 
Broker Y directly to client C. 



A method for locating services in a wide area inter- 20 
net network in accordance with Claim 1 . further in- 
cluding the steps of: 

registering, with a Notary, an advertisement 
generated by a Server, 2 . 5 
providing, by the Notary, authentication for the 
Servers it represents, and 
multicasting, by the Notary, the advertisements 
for the Servers registered with the Notary. 

30 
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FIG. 2 



START: SERVER X IS TURNED ON. IT PROVIDES SERVICE A. (goto 1) 

1. SERVER X FORMULATES AN ADVERTISEMENT FOR SERVICE A AND 
MULTICASTS IT INTO MULTICAST GROUP G. FROM THEN ON! SERVER 
X MULTICASTS ITS ADVERTISEMENT PERIODICALLY. " (goto 2) 

2. BROKER Y, WHICH OFFERS 6R0KER SERVICE FOR SERVICE A HEARS 
SERVER X's ADVERTISEMENT. ANO STORES IT IN ITS DATABASE 
(goto 3) 

"3. BROKER Y'SENOS AN ADVERTISEMENT FOR SERVICE A-BROKER, 
ANO MULTICASTS IT INTO A MULTICAST GROUP G2. IT WILL 
MULTICAST IT'S A-8R0KER SERVICE ANNOUNCEMENT PERIODICALLY 
FROM THEN ON. (goto 4) 

4. DIRECTORY AGENT Z HEARS THE A -BROKER SERVICE 
ANNOUNCEMENT FROM Y. IT NOTES THAT Y PROVIDES A -BROKER 
SERVICE. ANO STORES THIS INFORMATION IN ITS DATABASE, igcta 

5. CLIENT C WISHES TO FIND A SERVER FOR SERVICE A. {qoto 5) 

6. CLIENT C CONTACTS DIRECTORY AGENT Z. ANO QUERIES IT FOR 
RECORDS OF BROKERS PROVIDING BROKER SERVICE FOR SERVICE A 
(goto 7) 

7. DIRECTORY AGENT Z CHECKS ITS DATABASE. FINOS A MATCH FOR 
BROKER Y. AND RETURNS Y"s AOORESS TO C (goto 8) 

8. CLIENT C CONTACTS Y. ANO ASKS FOR A SERVER PROVIDING 
SERVICE A. (goto 9) 

9. BROKER Y CHECKS i*S DATABASE. FINOS A HATCH !N SERVER X' = 
RECORD. AND RETURNS THE ADDRESS ANO CHARACTERISTICS ON X. 
(goto !0) 

10. CLIENT C CONTACTS SERVER X FOR SERVICE A. 



3 



EP 0 892 530 A3 



0 



EUROPEAN SEARCH REPORT 

EP 98 30 5389 



DOCUMENTS CONSOERED TO BE RELEVANT 



i i tmm. iiw.imo»tx 

APAJGATOM mja.9) 



SCHWARTZ n F: 'INTERNET RESOURCE 
0ISC0VERY AT THE UNIVERSITY OF COLORADO" 
COMPUTER, IEEE COMPUTER SOCIETY, L0N6 
BEACH. , CA, US, US, 
vol . 26, no. 9 t 

1 September 1993 (1993-09-01), pages 
25-35, XP000395674 
ISSN: 0018-9162 

* page 26, left-hand colum, Itne 35 - 
line 45 * 

* page 33, left-hand colum, line 5 - line 
45 * 

* figure 3 * 

PETERSON L L: "A TELLOW-PAfiES SERVICE FOR 
A LOCAL-AREA NETWORK* 

COMPUTER C0MMJNICAT10NS REVIEW .ASSOCIATION 
FOR COMPUTING MACHINERY. NEW YORK, US, 
vol . 17, no. 5, 

1 August 1988 (1988-08-01), pages 235-242, 

XP0O2O61706 

ISSN: 0146-4833 

* abstract * 

* paragraph '0002! * 

US 5 227 778 A (VISSER JOHN A ET AL) 
13 July 1993 (1993-07-13) 

* abstract * 

» column 1, line 55 - column 2, line 46 * 

E? 0 491 069 A (IBM ScNEA ;IBM (US) ) 
24 June 1992 (1992-06-24) 

* abstract * 

* page 2, line I - line 25 * 

* figure 1 * 



.1-3 



•x cwQctt has dm tfnn up tor ail cairns 



HO4L29/06 
H04L12/18 
H04L29/12 



606F 
H04L 



MUNICH 



28 June 2001 



Poggio. F 



CAITGOflV OF CTTBD DOCUMENTS 



«■!**.- (PA OOOlTTWr, DUX 3bOfitf*«C an, 




C 



S narrow J fftt wm OMm>\ ,1rwy <*crf'**c*><<a.r.si 



(19) 



Europaisehes Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(11) EP 0 892 530 A3 

EUROPEAN PATENT APPLICATION 



(88) 


Date of publication A3: 


/51* inrri7 HOdl 50/06 H04L 12/18 




22.08.2001 Bulletin 2001/34 


H04L 29/12 




Date of publication A2: 






20.01.1999 Bulletin 1999/03 




\^ 1 ) 


Amplication number 98305389 3 




(22) 


Date of filing: 07.07.1998 




(84) 


Designated Contracting States: 


(72) Inventors: 




AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


• Rosenberg, Jonathan David 




MC NL PT SE 


Morganville. NJ 07751 (US) 




Designated Extension States: 


• Suter, Bern hard 




AL LT LV MK RO SI 


Aberdeen, NJ 07747 (US) 






• Schulzrinne, Henning Gunther 


(30) 


Priority: 18.07.1997 US 53026 P 


Leonia, NJ 07605 (US) 




22.04.1998 US 64581 P 








(74) Representative: 


(71) Applicant: LUCENT TECHNOLOGIES INC. 


Watts, Christopher Malcolm Kelway, Dr. et al — 




Murray Hill, New Jersey 07974-0636 (US) 


Lucent Technologies (U K) Ltd, 






5 Mornington Road 






Woodford Green Essex, IG8 OTU (GB) 



(54) Method for wide area network service location 



(57) A method for a client to locate a particular serv- 
ice from a service provider on wide area computer net- 
works. The method includes multicasting of an adver- 
tisement from a sen/ice provider, whicn advertisement 



is detectea by a Service Broker and in turn multicast into 
the wide area computer network. A client queries the 
network when seeking a particular sen/ice and receives 
in turn the address of the Broker and a Server to obtain 
the service desired. 
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